Release 10.1A: OpenEdge Development:
Java Open Clients
Managing a ProDataGraph through the update cycle
The OpenEdge
ProDataGraphprovides built-in support for tracking updates with itsProChangeSummaryobject. This object keeps track of what rows are changed (modified, added, or deleted) in theProDataGraphand also keeps track of the original versions of modified or deleted rows so you can compare those rows against the current rows. For more information on theProChangesSummaryobject, see the "ProChangeSummary class" section. In the procedure that follows, this and other OpenEdge support facilitates management of the ProDataSet update cycle in a Java Open Client application.
![]()
To manage a
ProDataGraphthrough an update cycle:
Note: While the actual parameter passing mode is application service dependent, an- Receive your working
ProDataGraphas anOUTPUTparameter of the application service. For more information, see the "Passing a ProDataGraph as OUTPUT" section.OUTPUTparameter is typical for an OERA-compliant application.- Make changes to the
ProDataGraphon the client:
- For information on finding rows in a ProDataGraph, see the "Finding a row in a ProDataGraph" section.
- For information on modifying rows, see the "Adding data to a ProDataGraph" section
- For information on adding rows, see the "Adding a row to a ProDataGraph" section.
Note: Because the application service sees the changes in its input ProDataSet using before-tables, all temp-tables subject to update are defined on the AppServer using the- For information on deleting rows, see the "Deleting a row from a ProDataGraph" section.
BEFORE-TABLEoption. To verify that a temp-table whose data you plan to update is defined with this option, you can check thebooleanvalue returned from thegetBImageFlag()method on theProDataObjectMetaDatathat corresponds to this temp-table. If the value istrue, you can update the correspondingProDataObjectcollection and the application service can handle the updates.- Extract a separate changes-only
ProDataGraphfrom your workingProDataGraphusing the followingProChangeSummarymethod:
Note: While the actual parameter passing mode is application service dependent, an- Pass the changes-only
ProDataGraphback to the application service using anINPUT-OUTPUTparameter. This allows the results to be passed back to the client in the same parameter.INPUT-OUTPUTparameter is typical for an OERA-compliant application.- Process the results from the application service in the output of the changes-only
ProDataGraphthat you passed to the AppServer in Step 4. ThisProDataGraphnow contains any additional changes, including errors, returned from the AppServer:
- Handle any errors that might be returned for each
ProDataObjectas well as theProDataGraphas a whole. For more information on checking errors, see the "Checking for errors" section.- Check the final changes in the output changes-only
ProDataGraphusing the methods of itsProChangeSummaryobject. For more information, see the "ProChangeSummary class" section. Compare the changed rows to the corresponding row in your working outputProDataGraph. Update the original row and add or delete additional required rows as described in Step 2.- Once you have merged all final changes into your working
ProDataGraphin Step 5, use this method to accept all changes in theProDataGraph:
This clears out the list of changes in the
ProChangeSummaryof yourProDataGraph, allowing it to accept more changes.- Update any UI appropriately for your updated working
ProDataGraph.- You can now accept more changes to the working
ProDataGraph, as in Step 2, restarting the update cycle, again.
|
Copyright © 2005 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |